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Abstract 

Isupov A.Yu. 

New software of the control and data acquisition system for the Nuclotron internal 

target station 

The control and data acquisition system for the internal target station (ITS) of 
Nuclotron (LHEP, JINR) is implemented. The new software is based on the ngdp 
framework under the Unix-like operating system FreeBSD to allow easy network 
distribution of the online data collected from ITS, as well as the internal target 
remote control. 

The investigation has been performed at the Veksler and Baldin Laboratory of 
High Energy Physics, JINR. 
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1 Motivation and markup 

The current version of the Nuclotron internal target station (ITS) is described in 
pp. The stepper motor and microstepper driver are still the same after the earliest 
ITS version 121. 
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Figure 1: Functional scheme of the internal target control. 



During the 2010-11 years the ITS control system was reimplemented to achieve 
the following goals: 

• replacement of outdated DOS software, which does not support either the network, 
or the underlying computer hardware; 

• replacement of the specific (almost unique now) CAMAC modules by the more 
generic ones with higher availability and repairability; 

• integration of the already implemented targinfo(l) server, which as a workaround 
was used separately (under the SCAN DAQ [3J) from the internal target DOS soft- 
ware. 

The present paper is focused on the software of the new ITS control and data 
acquisition (IntTarg CDAQ) system. The CAMAC hardware being used now by the 
IntTarg CDAQ is shown in Fig. [Tj, where we can see JINR manufactured generic 
modules only. 

Through the present text the file and software package names are highlighted 
as italic text, C and other languages constructions and reproduced "as is" liter- 
als - - as typewriter text. Reference to the manual page named "qwerty" in 



the 9-th section is printed as qwerty(9). Note also verbal constructions like u ac- 
cept(2)ed" and "mkpeering", which mean "accepted by accept(2) n and "peer mak- 
ing by mkpeer". Subjects of substitution by actual values are enclosed in the angle 
brackets: <cnts_mask>, while some optional parameters are given in the square 
brackets: [-b<#>] . 

2 IntTarg CDAQ software 

2.1 ngdp based design 

As it was noted in [4] , the ngdp framework could be used to organize and manage 
the data streams originated, in particular, from the CAMAC hardware. To reach 
some independence on the CAMAC crate controller type, we use the current version 
of the camac package [5]. The ngdp using allows us to eliminate intermediate data 
storage on slow media like hard disks (HDD), as well as to gracefully distribute the 
data acquisition system between more than one networked computers if needed [6]. 
Of course, the ngdp usage essentially reduces the implementation efforts, as it is 
shown in 12.21 

In the presented design of the user context utilities we adhere to the ngdp and 
its predecessor qdpb [7] convention when some command-line flags have the same 
meanings for many utilities, as follows: 

-1 Write logging information by syslogd(8), facility L0G_L0CAL0 (may be changed 
while compiling), levels L0G_ERR and LOG_WARNING instead of the standard 
error output. 

-v Produce verbose output instead of the short one by default. 

-b<#> Deal with the module, attached to the #-th branch, instead of the 0-th by 
default. 

-p<pidf ile> At startup write the own process identifier (PID) in <pidf ile>. -p- 
means to use a compiled-in default for <pidf ile>. 

-h Write the utility usage to the standard error output and exit successfully. 

So, in the specific utilities description we will not mention these flags. Note also, 
that each utility exits if it is successful and nonzero — if an error occurs. 

2.2 Ready modules used by IntTarg CDAQ 

In the IntTarg CDAQ design we use the following already implemented entities 
(introduced by the ngdp framework, if not stated otherwise): 

• The ng_ksocket(4) and ng_socket(4) node types are standard in the net- 
graph(4) package. 



• The ng_camacsrc(4) node type (see [I]) allows us to inject data packets from a 
CAMAC interrupt handler (see 12. 3.1]) into netgraph(4) as data messages. 

• The ng_fifos(4) node type (see [I]) implements the "selfflow"[J queue with First 
Input First Output (FIFO) discipline and is able to: 

| spawn listenOing ng_ksocket(4) at startup; 

f spawn accept ()ing ng_ksocket(4){s) at each connection request from the known 

host(s) / port(s) up to the configured maximum, and/or 

f accept hook connection from the local ng_socket(4){s); 

| emit each data packet obtained on the input hook as soon as possible (ASAP) 

through all accept ()ing ng_ksocket(4){s) and local ng_socket(4)(s) currently 

connected; 

| close accept ()ing ng_ksocket(4) at EOF notification obtaining or connection 

loss. 

• The ngget(l) (see [1]) is a utility for the packet stream extraction from net- 
graph(4) (usually through the ng_socket(4) node type). 

• The writer (1) is a utility for packet stream writing into regular files on HDD, 
and introduced by the qdpb system [7J. 

2.3 Modules specific for IntTarg CDAQ 

2.3.1 CAMAC kernel module inttarg(4) 

The inttarg module is intended to work with the ITS CAMAC hardware, com- 
plies with requirements of the camacmod(9) and ng_camacsrc(4), so, it contains 
the CAMAC interrupt handler function. This handler recognizes the following in- 
terrupt occurrences (events): 

• begin of burst (BoB), 

• target arrival to the initial position (InPos), and 

• target departure from it. 

In total 8 packet types INTTARG_CYC_{BEG,END,END[123] }, INTTARG_INF_0, and 
INTTARG_RUN_{BEG,END} are produced. Note the INTTARG_DAT_0 is not produced 
at all, because trigger events are absent in the present design. All 4 END packets 
have a variable length, while all the others — the fixed one. 

At each BoB occurrence the inttarg produces the INTTARG_CYC_BEG packet, 
which contains at least the time stamp (struct timeval) of the BoB. 

If the target should be active during the current burst, the corresponding (per- 
quantum) callout(9) handler is established to be executed once per our time 
quantum (compiled-in default is 10 msec, usually it equals to 10 OS ticks). Af- 
ter each quantum this handler increments the index in the trajectory description 
array already supplied by itoper(8), reads the member at this index, resets the 
effective microstep frequency and direction according to this member value, col- 
lects the experimental data from the ADC, and reestablishes itself. After the final 



1 Without internal bufferization and therefore request-free. 



quantum the per-quantum handler produces the INTTARG_CYC_END2 packet (ADC 
data) and wakes up the kernel thread kthread(9) to read the memory buffer of the 
10MSC multiscaler and produce the INTTARG_CYC_END1 (magnetic field from the 9th 
10MSC up/down input), INTTARG_CYC_END3 (the 0..7th 10MSC regular inputs) and 
INTTARG_CYC_END (target trajectory from the 8th 10MSC up/down input) packets. 
Note that INTTARG_CYC_END packet always is the latest data packet of the current 
burst, while INTTARG_CYC_END[123] are optional (depending on the software con- 
figuration). 

The INTTARG_CYC_END packet contains up to l+arr_size+l of intl6_t values. 
The arr_size is a basic size of internal arrays in the inttarg and configured by 
itconf(8), valid values are: 100.. 500, by default 500. The first (0th) intl6_t value 
contains the union inttarg_cyc_end_qdt (see einttarg.h), which has the quaval, 
dtype and tnum fields. The quaval is a time quantum duration (10 msec), the dtype 
is a data type (valid values are INTTARG_CYC_END_{INACTIVE,MKSTEPS, 1.10MM, INVALID}, 
see einttarg.h), and the tnum is a current target number (1..6). For our case of the 
active target the dtype is equal to INTTARG_CYC_END_MKSTEPS (or 1_10MM, if the 
inttarg is compiled without 10MSC support and the reported trajectory is cal- 
culated instead of the really read-out one). Each other intl6_t value is a signed 
microstep's number of the stepper motor during the corresponding time quantum. 
The positive values mean the movement from InPos, the negative ones — to InPos. 

The INTTARG_CYC_END1 packet contains up to l+arr_size+l of intl6_t values. 
The first (0th) is the union inttarg_cyc_endl_qf (see einttarg.h). Each other 
intl6_t value is a signed magnetic field difference during the corresponding time 
quantum. Naturally, the positive values correspond to the field increasing, the 
negative ones — decreasing. 

The INTTARG_CYC_END2 packet contains up to l+ADC_CHANS*(arr_size+l) of 
uintl6_t values. The first (0th) equals to ADC_CHANS constant (= 4, means the num- 
ber of ADC channels, numbered from the 0th to the 3rd). After the first uintl6_t 
the ADC_CHANS uintl6_t values represent the 1st time quantum, next ADC_CHANS 
uintl6_t values -- the 2nd time quantum, etc., and ADC_CHANS uintl6_t values 
for the arr_sizeth final quantum. The 1st ADC channel is modified to obtain the 
thermocouple output to control the stepper motor temperature. The ADC value to 
temperature conversion is as follows: T (°C)= — 0.625 xADC+628. 75. 

The INTTARG_CYC_END3 packet contains up to l+msclOnch*(arr_size+l) of 
uint32_t values. The first (0th) is the union inttarg_cyc_end3_cnt (see eint- 
targ.h), which contains, in particular, the msclOnch and msclOmask fields. The 
msclOnch is a number (valid are 0..8) and the msclOmask is an 8-bit mask (valid 
are 0..0xff) of the used 10MSC regular inputs. The mask could be configured by 
itconf(8). After the first uint32_t the msclOnch arrays with the same length (up 
to arr_size+l members) contain the uint32_t values of the 10MSC counts. 

If the target should be inactive during the current burst, the end-of-burst (EoB) 
callout(9) handler is established to be executed after arr_size of 10 msec time 
quanta. The EoB handler produces only the INTTARG_CYC_END packet with an 



empty trajectory. This means that the packet contains the union inttarg_cyc_end_qdt 
only, where the dtype is equal to INTTARG_CYC_END_INACTIVE. 

The INTTARG_RUN_BEG and INTTARG_RUN_END are produced at start and stop 
user requests (see itoper(8)) and contain the time stamps (struct timeval). 

The INTTARG_INF_0 packet is produced to indicate the operation in progress or 
some error or warning condition, and it should be interpreted by the receiver (for 
example, itGUI(l) utility). The INTTARG_INF_0 packet contains: int32_t value 
of the operation code (see toper_op.fi), intl6_t value of the error or warning code 
(see inttarg_err.h and errno(2)), and intl6_t value of the attribute (for example, 
the current target number at the WARN_CHTARG warning). 

The inttarg module can be configured by the itconf(8) and controlled by the 
itoper(8) / itGUI(l) utilities. The inttarg's oper() call supports at least the 
sub-functions enumerated in the itoper(8)s synopsis (see 12.3.2]) . Generally speak- 
ing, the corresponding operations have the essentially asynchronous nature, so, we 
implement some kind of the finite state machine. This machine transits between well 
defined states as a result of these operations execution. First of all, each operation 
should be added by the oper() into the FIFO queue (if a well defined operation or- 
der permits it after the last already added operation). The queue is implemented by 
the singly-linked tail queue STAILQ (see queue (3)), and the operation is represented 
in it by the struct op_entry (see toper. h). Each successfully added operation will 
be executed. Note that addition and execution are performed simultaneously with 
mutex(9) locking arbitration. Execution is completed in two phases: execution 
itself (i.e. some work with CAMAC) and asynchronous finish. The execution phase 
is performed by the oper() (if queue contains this command only), or by the kernel 
thread (after finishing the previous operation). The finish phase is made by the 
kernel thread waked up by IRQ handler, EoB or per-quantum callout(9) handler, 
or by own timed-out sleep(9). Operation can have one or more repetitions. So, 
cycles # operation has # repetitions, while the targon one is continuous (up to 
the targoff operation appearing in the queue). The operation execution and/or 
finishing failures lead to the queue discarding and the finite state machine appearing 
in the "unknown" (non-initialized) state. 

The CAMAC hardware description and handling are separated from the inttarg 
module's source and grouped together in the single header inttarg Jiardw are. h . This 
header uses macro interface kk(9) specific for the KK009 crate controller [8] instead 
of the crate controller independent interface camac(9), because the former interface 
allows us to slightly reduce the overhead for each CAMAC cycle 0. 

2.3.2 Configuration itconf(8) and control itoper(8) utilities 

itconf [-1] [-v] [-f<pflag>[,<pflag>. . .]] [-s{<arr_size> I -}] 

[-m<cnts_mask>] [-a] [-d{<driver> I -}] <module> 
itconf -t [-1] [-v] <module> 

In the first synopsis form the iteon/utility configures the specified module <module> 



(in our case usually inttarg, see 12.3. H and inttarg(4)) for work with driver kkO by 
default and produces packets with F_CRC|F_TIME (#defined in the packet. h) flags 
by default. 

In the second synopsis form the itconf utility tests the configuration of the spec- 
ified module <module> and writes it to the standard error output. 

The default behavior of itconf may be changed by the following options: 

-d<driver> Configure module for work with driver <driver> instead of default 
kkO. -d- means to use the compiled-in default for the driver. The default 
driver name may be changed at itconf compile time. 

-f<pflag> Set header. flag field in the make_pack() produced packets in accor- 
dance to the <pflag> supplied. Valid values are: "crc", "time", "none" (see 
packet(3) for more details). 

-s<arr_size> Set the size (number of members) of the arrays, which accumulate 
some statistics during the burst, to <arr_size>. Valid values are: 100. .500 
(corresponds to the burst of 1..5 sec), -s- means to use the compiled-in default 
for <arr_size> (500), which can be changed at itconf compile time. 

-m<cnts_mask> Set the bit mask for the 10MSC counter regular inputs, which will 
be read from CAMAC by configured module <module>. The <cnts_mask> 
value means as follows: the 0th nonzero bit marks the 0th counter input to 
be used, the 1st bit — the 1st input, etc., up to the 7th bit for the 7th input, 
-m absence in the command string leads to using the compiled-in default for 
<cnts_mask> (Oxf f , means -- to use all 8 inputs), which can be changed at 
itconf compile time. 

-a Request to read ADC0..3 at each time quantum and produce INTTARG_CYC_END2 
data packets with corresponding data. By default (without -a) the ADC1 is 
still being read at EoB or Final Quant and reported at INTTARG_CYC_BEG 
packets. 

itoper [-1] [-v] [-b<#>] init I f inishl start I stop I targonltargof f 

I status | cntcl I exec I done I clean I print 
itoper [-N<#>] [-1] [-v] [-b<#>] targon 
itoper -C<#> [-N<#>] [-1] [-v] [-b<#>] cycles 
itoper -T<#> [-1] [-v] [-b<#>] chtarg 
itoper [-r{<infile>|->] [-1] [-v] [-b<#>] [-A<amax>] [-V<vmax>] 

[-c{- I <limsf ile>}] settrj 
itoper [-s{<outfile>|->] [-1] [-v] [-b<#>] gettrj 

In all the synopsis forms the itoper performs operO call (see [I] and camac- 
mod(9)) with sub-function fun (see inttarg. h), defined by the first supplied argu- 
ment, on the CAMAC module (usually inttarg(4)) attached to the 0-th branch, 
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and writes the report about that action to the standard error output. The init, 
finish, start, stop, targon, targoff, cycles, chtarg, settrj, gettrj, status, 
and cntcl are funs for production usage and expected to have self-explained names. 
Note with -v the itoper also uses oper() call with status sub-function. The itoper 
may be used, for example, to implement some commands in the supervisor configu- 
ration file sv.conf(5) (see 12.3.31) . 

The default behavior of itoper may be changed, in particular, by the following 
options: 

-C<#> This mandatory flag supplies the number of cycles <#> to be serviced by the 
internal target before the implicit stop (the third synopsis form of the itoper). 

-N<#> If this optional flag is supplied, the one (last) of each <#> cycles will not 
be serviced by the internal target --so called "drop each N-th cycle" mode 
(the second and third synopsis forms of the itoper) . This allows another beam 
activity, for example, slow extraction. At the beginning of each burst previous 
to the inactive one the packet of INTTARG_INFO_0 type with WARN_PREP2DR0P 
value will be generated. 

-T<#> This mandatory flag supplies the internal target number <#> to be made 
active (the fourth synopsis form of the itoper). Valid values are 1..6. 

-r<inf ile> This optional flag supplies the <inf ile> name of the input file which 
contains the internal target trajectory to be programmed (the fifth synopsis 
form of the itoper). -r- means to use the compiled-in default for input file 
name ($NGDPHOME/trj/in.trj) , which can be changed at itoper compile time. 
The same is used if the -r is absent. 

-s<outf ile> This optional flag supplies the <outf ile> name of the output file 
where the current internal target trajectory should be stored (the sixth synop- 
sis form of the itoper). -s- means to use the compiled-in default for output file 
name ($NGDPHOME/trj/save.trj), which can be changed at itoper compile 
time. 

-A<amax> Sets the acceleration upper limit (in mksteps/msec 2 ) for the trajectory 
calculation to the supplied <amax> value. Default is 0.025. 

-V<vmax> Sets the velocity upper limit (in mksteps/msec) for the trajectory calcu- 
lation to the supplied <vmax> value. Default is 5.0. 

-c<limsf ile> Requires to read at startup the multipliers for the acceleration and 
velocity limits from <limsf ile> (the fifth synopsis form of the itoper). -c- 
means to use compiled-in default for <limsf ile> ($NGDPHOME/etc/itGUUims.cfg), 
which can be changed at itoper compile time. The same is used if the -c is 
absent. If the limits file opening or reading fails, the multipliers are 1.0 for the 
whole time range (0..5000 msec). 



The <inf ile> and <outf ile> contain the pair of ASCII float numbers delimited 
by space and/or tab symbol(s) per each line. (Lines are delimited by the newline 
symbol as it is usual for UNIX textual files). The first number is the time in msec 
(abscissa), the second - - a rotating angle in arc degrees (ordinate). Lines with 
comment symbol "#" in the first position are ignored. For example, the requested 
trajectory in Fig. [3] is as follows: 
#time position (degrees) 


900 33.2 

3300 35.0 
4300 

Each line of the <limsf ile> contains the four fields delimited by space and/or 
tab symbol(s). (Lines are delimited by a newline symbol as it is usual for UNIX 
textual files). The first field is a keyword, the alim means the line belongs to the 
acceleration's limitation, the vlim --to the velocity's one. The fourth field is an 
ASCII float and represents the multiplier for the limit, which is defined by the -A/-V 
option or by default. The second and third fields are ASCII integers from to 499 
and represent the lower and upper boundaries of the trajectory range (in the 10 msec 
units), where the multiplier will be applied. Lines with comment symbol "#" in the 
first position are ignored. For example, the requested trajectory in Fig. [3] uses the 
following limit multipliers: 

mult 

7.0 

0.3 

1.2 

2.3.3 The itGUI(l) user control utility 

itGUI [-1] [-v] [-b<#>] [-a] [-L] [-M<mask> I -m<mask>] [-A<amax>] 

[-V<vmax>] [-r{infile|-}] [-s{outf ile I -}] [-p{- |<pidf ile>}] 

[-c{-|<limsfile>}] 
itGUI -o [-1] [-v] [-b<#>] init|finish|start|stop|targon 

I targof f | status I cntcl I exec I done I clean I print 
itGUI -o [-N<#>] [-1] [-v] [-b<#>] targon 
itGUI -o -C<#> [-N<#>] [-1] [-v] [-b<#>] cycles 
itGUI -o -T<#> [-1] [-v] [-b<#>] chtarg 
itGUI -o [-r{<infile>|->] [-1] [-v] [-b<#>] [-A<amax>] [-V<vmax>] 

[-c{- I <limsf ile>}] settrj 
itGUI -o [-s{<outfile>|-}] [-1] [-v] [-b<#>] gettrj 

The itGUI provides the graphic user interface (GUI) for conversation with the 
IntTarg CDAQ system as well as for the graphic representation of the read out ex- 
perimental data using the ROOT framework [10] libraries. In the first synopsis form 
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Figure 2: The itGUI(l) screenshot. See text for description. 



the itGUI draws one main window of buttons (in Fig. [2]- the right window "Internal 
Target GUI") and some additional windows to display target trajectories (the upper 
left window) and other acquired data: magnetic field (the same window), multiscaler 
input (s) (the lower left window) and ADC channels (not shown). After that the it- 
GUI tests the current IntTarg CDAQ state to highlight buttons, correspondingly, 
launches the child process to read ngdp packets from the standard input (usually 
supplied by the ngget(l)), and goes into the endless loop (TApplication: :Run()) 
of the graphic events handling. Note the itGUI could be safely and consistently 
restarted at any time during the IntTarg CDAQ working without the latter state 
changes. 

If the itGUI called with the -o flag or under the itoper name, it behaves the 
same way agj itoper(8) utility in the corresponding synopsis forms (without -o, of 
course) , see 12.3.21 

The default behavior of itGUI may be changed, in particular, by the following 
options^: 



2 The itGUI(l) shares the corresponding source with the itoper (8). 

3 Options already described in !2.3.2l are not mentioned here. For the <inf ile>/<outf ile> and 
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Figure 3: The itGUI(l) trajectories window. See text for description. 

-a Handle ADC0..3 histograms instead of ADC1 channel only for the stepper motor 
temperature calculation by default. 

-L Leave mode — to survive after the data reading child process termination (usu- 
ally after EOF obtaining while the offline data file reading). It allows us to 
play with the graphic output without future redraws. 

-M<mask> Supplies the 8-bit mask <mask>, whose bits correspond to 10MSC regular 
inputs. Each nonzero bit means the corresponding counter to be additive dur- 
ing the current run instead of the counter resetting per each cycle by default. 

-m<mask> The same as -M, however, it normalizes additive counters to the packet's 
number. 

The itGUIis implemented with having in mind the supervisor utility concept (see 
[7]). According to this concept the itGUI has the configuration file (named by default 
$NGDPHOME/etc/inttargsv.conf) in the sv.conf(5) format (really Makefile, see 
also make(l)). This file establishes the correspondence between the user commands 



<limsf ile> formats see !2.3.2l 
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Figure 4: The itGUI(l) counters window. See text for description. 

("targets" in make(l) terminology) and actions which should be performed. This 
textual file could be revised easily without the itGUI recompile. 

The main itGUI (1) window (TGMainFrame) contains (see Fig. [2]) the buttons 
(TGTextButton), the string (TGTextEntry) and number (TGNumberEntry) input 
fields, the current state and target indication fields (TGLabel), and debug output 
viewer (TGTextView). Each button could be pressed by the left mouse button single- 
click, as well as the input focus could be placed into the input fields. The generic 
system startup direction is from up to down (and system stopping — from down to 
up). The buttons with "On" and "Off" meanings are placed in the same horizontal 
"engraved" frame from the left to the right. 

Each button could be in the following states: 

• active (could be pressed, black foreground); 

• pressed (reverse shadow, grey foreground); or 

• inactive (could not be pressed, grey foreground). 

Each button could display the following operation states: 

• the operation could be tried to perform (grey background); 

• the operation successfully done (green background); 

• the operation in progress or in queue (yellow background); 
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• the operation failed to be added to the queue or to be done (red background). 
The buttons are: 

Load loads and configures the inttarg(4) kernel module. The corresponding num- 
ber input fields: Counters Mask -- mask of the 10MSC input(s) to be read 
(O..0xff), Arrays Size - - base array's size (500 per 5 second accelerator 
burst). 

Unload (counterpart of previous) unloads the inttarg(4) kernel module. 

Exit sends SIGTERM to the itGUFs process group and exits the itGUI. Note the 
itGUFs termination does not change the IntTarg CDAQ state in any way. 

Status collects the status outputs from the number of system parts and displays 
these outputs in the debug output viewer. 

Readtrj reads the requested trajectory from the input file under the name given 
in the string input field to the right from the Readtrj button. This read- 
ing totally replaces the current requested trajectory, as well as its interactive 
modification, and leads to the calculated trajectory updating. 

Savetrj saves the current requested trajectory in the output file under the name 
given in the string input field to the left from the Savetrj button. 

Continue starts the data acquisition, i.e. handling of the BoB interrupts. In this 
state the system is ready for target walking, and the targinfo(l) server has 
the data to be distributed. 

Pause (counterpart of previous) stops the BoB interrupts handling. In this state 
the ITS hardware could be safely powered off/on. 

Settr j supplies the current calculated trajectory for the inttarg(4) kernel module. 

Gettr j gets the calculated trajectory from the inttarg(4) kernel module and prints 
it in the debug file under the name given in the string input field to the right 
from the Gettr j button. 

Chtarg sets the target with number <#> to be a current (ready to walk) target. 
The corresponding number input field: Target # — the number of the target 
to be the current one (valid numbers are 1..6). The correspondences between 
the numbers and materials are displayed to the right from the Chtarg group 
frame. 

Targon allows the current target to walk during each cycle infinitely (up to ex- 
plicit denying by the Targoff pressing). The target starts to walk at the 
nearest BoB. During the latest of each N bursts the target could be not walk- 
ing, if the N > 2 value is supplied with the corresponding number input field 
Drop each Nth. Valid numbers are 2. .3600, and 0, 1, which mean that the 
target does not drop the bursts. 
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Targof f (counterpart of previous) denies the current target to walk. The target 
stops to walk after the nearest EoB or before the nearest BoB. 

Cycles allows the current target to walk during each cycle of the nearest # cycles 
(or up to explicit denying by the Targof f pressing), supplied with the corre- 
sponding number input field Cycles number (valid numbers are 1..3600). The 
target starts to walk at the nearest BoB. During the latest of each N bursts 
the target could be not walking, if the N > 2 value is supplied with the corre- 
sponding number input field Drop each Nth. Valid numbers are 2.. 3600, and 
0,1, which mean that the target does not drop the bursts. 

Init initializes ITS hardware, in particular, CAMAC modules in the read-out crate, 
and positions the target into the nearest InPos. Note the Init is also a part 
of Load. 

Finish (counterpart of previous) de-initializes the internal target hardware. In the 
current design it is not needed at all. 

LoadW loads the writer (1) — utility to write the packet stream into files on HDD. 
The corresponding input fields: 

(string) - - base name of the data files for the current writer (1) run; 
Max. Size (bytes) (number) -- the recommended size for each file; 
Max. Age (seconds) (number) -- the recommended age for each file. 

UnloadW (counterpart of previous) unloads the writer(l) utility and consequently 
terminates the data writing of the current run. 

LoadTI loads the targinfo(l) -- server, which distributes the read out internal 
target trajectory to its already registered clients. 

UnloadTI (counterpart of previous) unloads the targinfo(l) server. 

Each but Exit, Readtrj, Savetrj button corresponds to the command (target) 
under the same name (without capitalization) in the supervisor configuration file, 
so the IntTarg CDAQ control has two functionally equivalent interfaces: graphic 
(by itGUI(l)) and textual (by configuration file make(l)ing). Note, however, 
that itGUI(l) itself uses the configuration file to perform the complex commands 
( [un] load, [un] loadw, [un]loadti, status) only. In contrast, the simple com- 
mands (see -o synopsis forms) corresponding directly to inttarg(4)s oper() sub- 
functions, are performed internally using the code shared with itoper(8). 

The indication fields in the main window are: 
Curr . State : (under the Status button) displays the current state of the operations 
queue (see 12.3.1"]) , one of: 'Unknown' (on grey background — before Load and 
after Unload, on red — otherwise), 'Init', 'Start', 'Stop', 'Cycles', 'Target On' 
(all on green). 
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Curr . Target : (to the right for the Chtarg button) displays the current target num- 
ber and material (on the green background — after successful target change, 
on the yellow one -- after startup and while the target changing, on the red 
- after the unexpected target change or after obtaining the invalid number 
of the current target), for example: '#5 Agl08'. 

The string input field named "Arbitrary command" (just above the debug output 
viewer) allows the user to perform any target from the supervisor configuration file. 

The itGUI(l) data windows are as follow: 
trj canvas The internal target trajectories - - requested (in black, with asterisk 
points), calculated (in red) and read out (in green, only after cycles with the 
active target) from the 8th 10MSC up/down input — as well as the magnetic 
field (in blue) read out from the 9th 10MSC up/down input are displayed in 
the single TCanvas named "trj canvas". On the itGUI screenshot (Fig. [2]) we 
can see this canvas as the left upper window frame with the "Target trajectory / 
Magnetic field" title. With the higher resolution such canvas is shown in Fig. [31 
The calculated (dotted) and read out (dash-dotted) trajectories are in some 
segments below the requested trajectory (the solid line with two asterisks) and 
approximately coincide. The last segment of the read-out curve goes to zero 
vertically, because the multiscaler is not read after the final time quantum, 
however, the target really goes into InPos with the fixed 1 mkstep/msec veloc- 
ity, as it is shown by the calculated curve. The arbitrary scaled magnetic field 
(dashed curve) is above all the others. The abscissa is the time in millisec- 
onds, the ordinate is a target shift in arc degrees (InPos at 0°, beam center 
approximately at 30°). Note, the requested and calculated trajectories could 
not be very close to each other (as in Fig. [3]), because the trajectory calculation 
algorithm has the upper limits for the target velocity (leads to the lower slope 
angle) and acceleration (leads the to angle smoothing). To be more flexible, 
these limits could be varied along the trajectory according to the configuration 
file itGUIJims.cfg (format described in l2.3.2p . So, the trajectory in Fig. [3] is 
calculated with the following limits: 
amax< 0.175 mksteps/msec 2 at 0..500 msec 
amax< 0.0075 mksteps/msec 2 at 500. .2000 msec 
vmax< 6.0 mksteps/msec at 0..1500 msec 

(in other time ranges the both limits are default). The requested trajectory 
could be read from the input file under the name given in the correspond- 
ing TGTextEntry by pressing the Readtrj (see above). Reading from the file 
totally replaces the current requested trajectory. The current requested tra- 
jectory could be interactively modified. The point could be added by the left 
mouse button double-click, while the existing point could be removed by the 
middle mouse button double-click (see also the hot keys below). Note, neither 
the points nor the whole trajectory should be moved. After each modification 
of the requested trajectory the calculated trajectory is updated. The current 
requested trajectory could be saved in the output file under the name given 
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in the corresponding TGTextEntry by pressing the Savetrj (see above). The 
following hot keys are supported while mouse focus is in "trj canvas": 
'a', 'A' — add the point under the current mouse position; 
'd', 'D' - - delete the point under the current mouse position; 
'i', T - - input the point using the TGInputDialog (the coordinates should be 
entered as the time-angle pair of the float numbers delimited by space and/or 
comma) ; 

'u', 'IT - remove the last point added by the left double-click, 'A', 'a', T, T 
(could be used many times); 

'p', 'P' - print the calculated trajectory into the debug file under the name 
given in the TGTextEntry to the right from the Gettrj (see above); 
'r', 'R' -- read out the requested trajectory from the input file under the name 
given in the TGTextEntry to the right from the Readtrj (see above); 
'c', 'C - clean out the trajectory (only (0,0) and (5000,0) points are pre- 
served) ; 

's', 'S' - save the current requested trajectory in the output file under the 
name given in the TGTextEntry to the left from the Savetrj (see above); 
T - supplies the current calculated trajectory for the inttarg(4) kernel 
module (the same as Settrj, see above); 

't' - - gets the calculated trajectory from the inttarg(4) kernel module and 
prints it in the debug file under the name given in the TGTextEntry to the 
right from the Gettrj (see above); 
'q', 'Q' - - quit the itGUI (the same as Exit button pressing, see above). 

cnts canvas From up to 8 counter values, read-out from the 0..7th 10MSC inputs, 
are represented by THIDs and displayed in the single TCanvas "cnts canvas" 
iconified at startup. In Fig. [2] it is the lower left window frame with the 
single curve, which represents the interaction intensity monitor counts for the 
last processed cycle. This plot allows the user to tune the target movement 
trajectory. Numbers and positions of the inputs to be used are configured 
(see itconf(8)) while loading of the inttarg(4) kernel module. The intensity 
monitor counts during the single cycle for the C target run is shown in Fig. HI 

cv_adc_N Four ADC channel histograms (THl) are displayed each in its own win- 
dow (TCanvas) "cv_adc_0".."cv_adc_3" iconified at startup (in Fig. [2] we can't 
see them), if the -a option is specified. 

2.3.4 The targinfo(l) trajectory server 

The targinfo (1) is a server, which provides its clients with the internal target 
trajectory data in each accelerator cycle at the end of this cycle. 

targinfo [-1] [-t] [-f<#>] [-p{- I <pidf ile>}] [-a<address> [ ...]] 
In this synopsis form the targinfo listens to the TCP/IP socket on the host 
hell7-90.jinr.ru, port 12345 to get client connection requests, and reads packets 

15 



from the standard input. From each of the obtained INTTARG_CYC_BEG packets the 
targinfo collects the BoB timestamp, while from each of the INTTARG_CYC_END ones 
it collects the microstep number array of the ITS stepper motor. Once per cycle 
the targinfo writes the cycle timestamp and some target trajectory data (format 
described below) to all the currently connected clients (if any). Up to CLIENTS_MAX 
clients (usually 5) can be serviced simultaneously, connections closed by the peer 
are recycled. 




[ outputo ] ( output2 




Figure 5: The IntTarg CDAQ core is implemented by the ngdp graph. 
Rectangles are nodes with: name (up), type (left), ID (right); 

octagons are hooks named within. 

ng_f if os has two local output streams through ng_sockets, 

as well as listen()ing ngJcsocket. 

The default behavior of the targinfo may be changed by the following options: 
-t Exits at all negative conditions from packet(3) functions instead of the exit 
only at —3 by default. 

-f <#> Assigns the supplied <#> number to the pack_f lags variable for the packet(3) 
read_pack() function, -f absence in the command string leads to using the 
compiled- in default for <#> (F_CRC (see packet. h), because this is the only 
checkable value for reading). 

-a<address> Restricts clients to connect from specified <address> only instead of 
allowing the client to connect from any one by default. <address> can be an 
Internet name in domain notation or IP address as four decimals separated by 
dots. Note that -a option can be specified with different <address>es up to 
CLIENTS.MAX times. 

The data format preserved after workaround implementation under the DAQ 
system of the SCAN setup [3] is as follows: 
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Figure 6: Overall IntTarg CDAQ layout. 

• timestamp of the burst begin (8 bytes of the struct timeval); 

• signed target shift in 1/10 mm per each 20 msec (the 250 intl6_ts allows us to 
cover up to 5 second burst). 

The format also indicates the following situations: 

• A nonactive target. If the target was not injected into the beam during the current 
cycle, all the 250 intl6_ts are equal to 0. 

• Some erroneous target behaviour. If the target was walking incorrectly, all 250 
intl6_ts are equal to SHRT.MAX (0x7ff f). 

• The next cycle will be nonactive. The ITS control supports a special operation 
mode, in which the target remains inactive each N-th of N cycles to allow other 
beam activities. In this mode, if the trajectory data are SHRT_MAX-1 (0x7f f e), the 
internal target will be inactive during the next cycle. Note, these data will be written 
soon after obtaining INTTARG_CYC_BEG packet in contrast with all the other data 
types generated at INTTARG_CYC_END arrival. Note also, that the normal trajectory 
output will be generated for the current cycle, too, and during the next (inactive for 
the internal target) cycle the trajectory data will be zero (as it should be expected). 

2.4 Bringing all things together 

The ngdp graph used by the IntTarg CDAQ is shown in Fig. [5j It is very much 
like ng dtp's CAMAC Front-End Modules (FEM) level proposed in [6]. The node 
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namedfifo: of type ng_f if os is instantiated (mkpeered) atthehell7-90.jinr.ru 
host bootstrap time using the script $NGDPHOME/etc/fifo.ngctl processed by the 
ngctl(l). During ng_f if os startup it mkpeers the node of type ng_ksocket with 
automatically chosen name (0x2_listen: in Fig. |5]), and connects the remote hook 
inet/stream/tcp with its own hook listen. So, the ng_f if os and its listen()ing 
ng_ksocket are still ready from OS's boot to shutdown. 

The ng_f ifos provides identical packet streams through all the currently con- 
nected outputs, both the local and remote ones. Each output could be connected 
and disconnected without disturbing other outputs, so the packet stream consumers 
(writer(l), targinfo(l), and itGUI(l)) could be started and terminated inde- 
pendently of each other. These utilities are launched by the loadw, loadti and 
loadgui commands from the $NGDPHOME/etc/inttargsv.conf to be readers of the 
pipes, where the writers are the ngget(l)s. Each ngget(l) mkpeers the ng_socket 
instance (ngget73583 : and ngget73547 : in Fig. \5§ and connects it by hook get 
with ng_f if os's hook output<N>. The simultaneously allowed numbers of both the 
output<N> hooks and accept Oing ng_ksockets are the compiled-in parameters of 
ng_f if os. 

The load command of the supervisor configuration file, in particular, loads the 
inttarg(4) interrupt handler and executes the ngctl(l) utility to proceed the script 
$NGDPHOME/etc/camacsrc.ngctl, which mkpeers the node named src: of type 
ng_camacsrc. This node communicates (see pi] for details) with CAMAC kernel 
module inttarg(4), and connects its own hook output with the hook input of 
the ng_f if os. After that the IntTarg CDAQ graph has all components which are 
provided by the current design. 

The supervisor configuration file $NGDPHOME/etc/inttargsv.conf allows the 
user to control the IntTarg CDAQ in the command-line mode through a simple 
textual terminal (without GUI). Of course, the requested trajectory could not be 
corrected interactively in this mode, and user can't see all the read-out data. How- 
ever, the trajectory file is textual (see 12.3.2"]) . so it could be edited easily. 

The overall IntTarg CDAQ layout is pictured in Fig. [HI where we can see the host 
hell7-90.jinr.ru as the rectangle entitled "IntTarg CDAQ". In the user context 
the three processes (itGUI(l), targinfo(l) and writer (1)) obtain three iden- 
tical packet streams from three ngget(l)s, which read three ngsocket(4)s con- 
nected to ng_fifos(4). The packet streams with the same contents could be also 
transferred remotely through the accept(2)ing ng_ksocket(4)s instantiated after 
client's connect (2)ion to the listen(2)ing ng_ksocket(4) ■ (The netgraph(4) 
behaviour mimics the BSD socket handling scheme.) In the present state we have 
no remote consumers of the full packet stream, however, they can appear in future 
(see 12311 . 

The rectangle "trajectory visualization client" in Fig. [6] is another host which 
executes one of the possible clients of the targinfo(l) server — the ROOT script 
clnt-targ.C . Note the targinfo(l) distributes the read out trajectory only, not the 
packet stream (see also I2.3.4p . So, the targinfo(l) is preserved mostly for the 
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backward compatibility and could be retired in future. 

2.5 Nuclotron run experience and future directions 

The IntTarg CDAQ was used to control the internal target during the March 
and December 2011 Nuclotron accelerator runs. The total beam time of the ITS 
operation was approximately 150 hours on the deuteron beam at T kin = 250-500 
MeV/nucleon. In particular, the "drop each N-th cycle" mode was successfully used 
in March 2011. 

The IntTarg CDAQ usage experience during the March 2011 Nuclotron acceler- 
ator run provides some hints to improve the software, first of all itGUI(l), in some 
aspects. So, the ROOT TGraph was replaced by the TH1D to represent most of the 
visualized curves with many (some hundreds) points since the TGraph has shown a 
dramatically low visualization performance (ROOT 5.16). Also the ROOT TThread 
was eliminated in favor of traditional UNIX child process f ork()ing to separate the 
execution stream for the data packets reading from the main execution stream for 
the Xll events handling. This choice has been justified by the fact, that the BSD 
scheduling algorithm for processes instead of threads is more mature, refined, and 
featured. The -a option was added to the itGUI(l) to reduce visualization ex- 
penses by default, and visualize ADC histograms with -a. If the same option is not 
supplied to itconf(l), the inttarg(4) module will be configured not to collect ADC 
data for histogramming, because these data are currently not useful. Only the step- 
per motor temperature channel (ADC1) will be read once per cycle (at EoB or final 
quantum). The corresponding value could be found at the end of INTTARG_CYC_BEG 
packet, which was enlarged by 2 bytes. This feature reduces the CAMAC activity 
overhead per each time quantum and allows to watch the stepper motor temper- 
ature also during the cycles with an inactive target. All the mentioned software 
improvements were successfully tested during the December 2011 Nuclotron run. 

The full IntTarg CDAQ system data set in the packet stream form could be 
provided online for clients on the remote hosts. A client could be something like 
a (sub)event builder ((Sub)EvB, see [6]) implemented in the kernel context by, for 
example, the following ngdp graph: ng_ksocket— ^ng_defrag— >ng_em[s] . In the 
user context a client could be, for example, a pipe of the hose(l) utility (writer 
end) from the netpipes package (see netpipes(l)) and a some read-only version of 
the itGUI(l) (reader end), which allows the user to observe but not control the 
internal target. Of course, users are free to implement their own clients using the 
BSD socket and ngdp packet(3) program interfaces (APIs). 

Some minor updates of the IntTarg CDAQ are also possible in future. A separate 
canvas for the trajectory changes and calculations during the target walking could 
be added. The magnetic field reading with the inactive target will be useful. The 
target trajectory calculation algorithm has some annoying features, so it could be 
revised more or less essentially. The 8th and 9th multiscaler input readings could 
be prolonged after the final quantum. 
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3 Conclusions 

The new control and data acquisition system for the Nuclotron ITS has been 
implemented using the ngdp, camac, and ROOT packages to allow easy network 
distribution and integration. The outdated both DOS software and underlying CA- 
MAC and computer hardware have been replaced. The previously implemented 
targinfo(l) server has been integrated into the IntTarg CDAQ now. During 150 
hours of the 2 Nuclotron runs the IntTarg CDAQ has demonstrated the operation 
stability and target manipulation convenience. 
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